The document discusses adopting agile methods for software development. It describes typical development environments, including challenges with waterfall and iterative processes. It then provides an overview of agile concepts, methods like Scrum and user stories, agile modeling practices, and test-driven development. The goal is to help organizations understand how agile differs from traditional methods and which agile techniques may help address common pain points in software development.
Mobile to Mainframe - the Challenges of Enterprise DevOps AdoptionSanjeev Sharma
Delivering software is complex. Systems being developed are made up of multiple components, which in turn interact with other systems, services, application servers, data sources and invocations of 3rd party systems. In an Enterprise this complexity is further enhanced by the cross-platform nature of the infrastructure typical enterprises have. While the customers may be interacting with Systems of Engagement using Mobile and Web Apps, the core capabilities of the enterprise that the customers access are in Systems of Record that are running on large datacenters and more than likely Mainframe systems. Keeping these complex systems up and running and constantly updated with the latest capabilities is a task that requires constant coordination between the lines of business, various cross-platform development, QA and operations teams.
DevOps addresses these development and deployment challenges. The goal of DevOps is to align Dev and Ops by introducing a set of principles and practices such as continuous integration and continuous delivery. Cross-platform enterprise Systems take the need for these practices up a level due to their inherent complexity and distributed nature. Such systems need even more care in applying DevOps principles as there are multiple platforms to be targeted, in a coordinated manner, each with its own requirements, quirks, and nuanced needs.
This talk will take a look at the DevOps challenges specific to Cross-platform Enterprise Systems and present Best Practices to address them.
A discussion of deployment options for IBM Collaborative Life Cycle Management. The IBM Rational CLM products consist of Rational Team Concert, Rational Requirement Composer and Rational Quality Manager. This presentation covers the different options of integrating them into an existing software development environment.
RDz for DevOps Webcast Series: Implementing Continuous Integration with RDzSusan Yoskin
How do you improve code quality and achieve continuous integration in a mainframe environment? Continuous integration testing, by shifting defect detection and resolution earlier in the delivery cycle (shift left approach), speeds up development while increasing quality and time to market. This session focuses on the development and test phase of the DevOps lifecycle. It centers on development using Rational Developer for System z (RDz), including debug, code review and code coverage. It discusses test automation using a customized zUnit testing framework in conjunction with automated mainframe SCM build and deploy. Keith Allen, IBM Software Sales European IOT Team Lead - DevOps for Enterprise z Systems, and Luis Carlos Silva, IBM EM Continuous Integration Lead and Product Line Manager, will take you through this methodology.
IBM's DevOps solution for CLM includes a full lifecycle suite of products for managing continuous business planning, Agile project management, continuous build, source code management, test management, and continuous application monitoring.
Mobile to Mainframe - the Challenges of Enterprise DevOps AdoptionSanjeev Sharma
Delivering software is complex. Systems being developed are made up of multiple components, which in turn interact with other systems, services, application servers, data sources and invocations of 3rd party systems. In an Enterprise this complexity is further enhanced by the cross-platform nature of the infrastructure typical enterprises have. While the customers may be interacting with Systems of Engagement using Mobile and Web Apps, the core capabilities of the enterprise that the customers access are in Systems of Record that are running on large datacenters and more than likely Mainframe systems. Keeping these complex systems up and running and constantly updated with the latest capabilities is a task that requires constant coordination between the lines of business, various cross-platform development, QA and operations teams.
DevOps addresses these development and deployment challenges. The goal of DevOps is to align Dev and Ops by introducing a set of principles and practices such as continuous integration and continuous delivery. Cross-platform enterprise Systems take the need for these practices up a level due to their inherent complexity and distributed nature. Such systems need even more care in applying DevOps principles as there are multiple platforms to be targeted, in a coordinated manner, each with its own requirements, quirks, and nuanced needs.
This talk will take a look at the DevOps challenges specific to Cross-platform Enterprise Systems and present Best Practices to address them.
A discussion of deployment options for IBM Collaborative Life Cycle Management. The IBM Rational CLM products consist of Rational Team Concert, Rational Requirement Composer and Rational Quality Manager. This presentation covers the different options of integrating them into an existing software development environment.
RDz for DevOps Webcast Series: Implementing Continuous Integration with RDzSusan Yoskin
How do you improve code quality and achieve continuous integration in a mainframe environment? Continuous integration testing, by shifting defect detection and resolution earlier in the delivery cycle (shift left approach), speeds up development while increasing quality and time to market. This session focuses on the development and test phase of the DevOps lifecycle. It centers on development using Rational Developer for System z (RDz), including debug, code review and code coverage. It discusses test automation using a customized zUnit testing framework in conjunction with automated mainframe SCM build and deploy. Keith Allen, IBM Software Sales European IOT Team Lead - DevOps for Enterprise z Systems, and Luis Carlos Silva, IBM EM Continuous Integration Lead and Product Line Manager, will take you through this methodology.
IBM's DevOps solution for CLM includes a full lifecycle suite of products for managing continuous business planning, Agile project management, continuous build, source code management, test management, and continuous application monitoring.
Eight deadly defects in systems engineering and how to fix themJoseph KAsser
Any organization desirous to adopt or improve systems engineering needs to be aware that research into the nature of systems engineering has identified a number of defects in the current systems engineering paradigm. This paper discusses eight of these defects and ways to fix or compensate for them.
On October 22, 2016, Oakwood Systems Group delivered a presentation at Dev Up covering Database Lifecycle Management with Redgate. Get the full presentation here.
Scaling the v6.0.x Collaborative Lifecycle Management (CLM) solution across an enterprise often includes multiple instances of a given Jazz application. What multi-Jazz application options are available and what are the considerations?
What topologies and general multi-Jazz application options are available
How Jazz applications such as Change Configuration Management (CCM), Quality Management (QM) and Requirements Management (RM) relate to a Jazz Team Server (JTS)
The impact, advantages and disadvantages of multiple CLM Applications
What to consider when scaling and developing usage models adopting one of these deployment options to avoid surprises
Jim and Bob's Excellent Database AdventureRonnie Hicks
“Hey Jim"
“Hey Bob, how’s it going?"
(mumble mumble)”It’s alright, I guess. We have another database push tonight. Looks like it’s going to be another late one. (sigh)"
“Aw Bob, I’m sorry to hear that. Well, I’ll be out golfing, let me know if you need anything! Bye!"
Familiar, right? Everybody’s had their rounds once or twice. Well, let’s talk about how we can turn grumbly Bob into happy Bob. This session will introduce a new tool to Bob’s job that will allow him to get that database changed, and have some fun too. There’ll be databases, a simple web interface, and some sparkly Red Gates that come to save the day. Come join us as we walk, run then frolic through the fields of Database Lifecycle Management.
We had this presentation running on one of the screens in our booth at the April 4, 2013, Innotech Dallas/SharePoint TechFest. We have been excited by the developments in the latest release of Visual Studio and it's ability to work seamlessly with Microsoft's Azure.
SCL Aug Sep 2010 Software Development How Agile Are Yoususanatkinson
'Software Development - How Agile are You?' - Article featuring in the August/September 2010 edition of the magazine for the Society for Computers & Law (SCL)
It concentrate on the development rather than managerial ascepts of software projects.
XP was designed so that organization would be free to adopt all or part of the methodology.
XP projects start with a release planning phase,followed by several iteration ,each of which concludes with user acceptance testing.
When the product has enough features to satisfy users, the team termination iteration and release the software.
Eight deadly defects in systems engineering and how to fix themJoseph KAsser
Any organization desirous to adopt or improve systems engineering needs to be aware that research into the nature of systems engineering has identified a number of defects in the current systems engineering paradigm. This paper discusses eight of these defects and ways to fix or compensate for them.
On October 22, 2016, Oakwood Systems Group delivered a presentation at Dev Up covering Database Lifecycle Management with Redgate. Get the full presentation here.
Scaling the v6.0.x Collaborative Lifecycle Management (CLM) solution across an enterprise often includes multiple instances of a given Jazz application. What multi-Jazz application options are available and what are the considerations?
What topologies and general multi-Jazz application options are available
How Jazz applications such as Change Configuration Management (CCM), Quality Management (QM) and Requirements Management (RM) relate to a Jazz Team Server (JTS)
The impact, advantages and disadvantages of multiple CLM Applications
What to consider when scaling and developing usage models adopting one of these deployment options to avoid surprises
Jim and Bob's Excellent Database AdventureRonnie Hicks
“Hey Jim"
“Hey Bob, how’s it going?"
(mumble mumble)”It’s alright, I guess. We have another database push tonight. Looks like it’s going to be another late one. (sigh)"
“Aw Bob, I’m sorry to hear that. Well, I’ll be out golfing, let me know if you need anything! Bye!"
Familiar, right? Everybody’s had their rounds once or twice. Well, let’s talk about how we can turn grumbly Bob into happy Bob. This session will introduce a new tool to Bob’s job that will allow him to get that database changed, and have some fun too. There’ll be databases, a simple web interface, and some sparkly Red Gates that come to save the day. Come join us as we walk, run then frolic through the fields of Database Lifecycle Management.
We had this presentation running on one of the screens in our booth at the April 4, 2013, Innotech Dallas/SharePoint TechFest. We have been excited by the developments in the latest release of Visual Studio and it's ability to work seamlessly with Microsoft's Azure.
SCL Aug Sep 2010 Software Development How Agile Are Yoususanatkinson
'Software Development - How Agile are You?' - Article featuring in the August/September 2010 edition of the magazine for the Society for Computers & Law (SCL)
It concentrate on the development rather than managerial ascepts of software projects.
XP was designed so that organization would be free to adopt all or part of the methodology.
XP projects start with a release planning phase,followed by several iteration ,each of which concludes with user acceptance testing.
When the product has enough features to satisfy users, the team termination iteration and release the software.
Introducing the Rational Solution for Agile ALMMatt Holitza
How do you keep your agile teams focused on the task at hand while still providing management with the latest status? Find out in this presentation from IBM Innovate 2013.
software design and architecture and its brief description about software patterns as well.software design and architecture and its brief description about software patterns as well.software design and architecture and its brief description about software patterns as well.software design and architecture and its brief description about software patterns as well.software design and architecture and its brief description about software patterns as well.software design and architecture and its brief description about software patterns as well.software design and architecture and its brief description about software patterns as well.software design and architecture and its brief description about software patterns as well.software design and architecture and its brief description about software patterns as well.software design and architecture and its brief description about software patterns as well.software design and architecture and its brief description about software patterns as well.software design and architecture and its brief description about software patterns as well.
Agile software development is a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change.
The Agile development model is also a type of Incremental model. Software is developed in incremental, rapid cycles. This results in small incremental releases with each release building on previous functionality. Each release is thoroughly tested to ensure software quality is maintained. It is used for time critical applications.
Let's dive deeper into the world of ODC! Ricardo Alves (OutSystems) will join us to tell all about the new Data Fabric. After that, Sezen de Bruijn (OutSystems) will get into the details on how to best design a sturdy architecture within ODC.
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
"Impact of front-end architecture on development cost", Viktor TurskyiFwdays
I have heard many times that architecture is not important for the front-end. Also, many times I have seen how developers implement features on the front-end just following the standard rules for a framework and think that this is enough to successfully launch the project, and then the project fails. How to prevent this and what approach to choose? I have launched dozens of complex projects and during the talk we will analyze which approaches have worked for me and which have not.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
2. IBM Rational Software Conference 2009
Agenda
Introduction
Typical Development Environments
Understanding Agile
Agile Methods - Scrum, Requirements, Modeling, TDD, CI
Game Plan to adopt Agile Methods
2
3. IBM Rational Software Conference 2009
Typical Development Environments
Which of these scenarios apply to your company?
A large corporation of employees with highly visible projects that have trouble delivering
on time or adapting to change because the existing process is elongated
A company that has multiple development sites that are geographically dispersed between
hemispheres or across the continent
A small or medium sized company of highly skilled workers unable to demonstrate value
and quick turnaround in a repeatable fashion
Many companies fall into one or more of these scenarios looking to for a way to
help with the pain
Agile techniques and practices are gaining more and more attention in the
software community
What’s not clear are the differences between the techniques
Which techniques should be adopted for your organization or project?
Then there’s the fear that you may lose productivity
3
4. IBM Rational Software Conference 2009
Typical Development Environments
Software development has evolved and changed drastically in the last 20 years
Technologies have evolved
Framework have been developed
Complex Tools created to ease the burden of developing software
Software development life should be easier by now right?
Truth is, software development has gotten heavily burdensome and overly complicated
What used to be quick in today’s environment takes much longer to accomplish
There just seems to be too many steps getting in the way of the primary goal to develop
software
4
5. IBM Rational Software Conference 2009
Typical Development Environments - Waterfall
In order to understand how or what to adopt, it’s important to understand what
Agile really means and how it differs from traditional development
To set the stage, consider the Waterfall based process:
Pros:
Simple, Well-defined milestones, Disciplined,
Ordered
Still used by the majority of large companies
Cons:
Risk is delayed until the very end. This costs money
if things go wrong.
What if the architecture won’t work?
What if System Testing identifies a major bug – or
worse, missed requirements?
5
6. IBM Rational Software Conference 2009
Typical Development Environments - Waterfall
Waterfall based processes demand thick documentation with a focus on many
physical artifacts (documents) that ended up becoming a series of forests cut
down
Why? It’s a hand-off – sometimes between groups
The single “Requirements Document” consisting of many, many pages handed over to
developers, testers, and business stakeholders
These are filled with declarative statements such as “The System shall ….”
In many cases, one document artifact gets copied or translated into other similar
documents
Requirements Specification to Technical Specifications to Design Specifications
All the while the notion of what the system is really supposed to do or how someone would
use that system becomes harder to see clearly amid all of the pages of documentation
Maintaining a system like this or adding new capabilities becomes more and more difficult
6
7. IBM Rational Software Conference 2009
Typical Development Environments - Iterative
Then along came iterative based development
It too was well defined
Risks were resolved earlier by developing incremental
behavior of the system and integrating sooner
Unlike Waterfall – which had a single release – functionality
could be deployed earlier in the lifecycle in a series of
releases
RUP, Spiral, MSF, OpenUP are examples of iterative
processes
Software created in time-boxed iterations
Each revision incrementally builds upon the
last working and tested software
7
8. IBM Rational Software Conference 2009
Typical Development Environments - Iterative
Iterative development processes like the RUP take a different approach
Use Cases used to capture functional requirements of a system organized in a sequence
of steps that yield some observable result to the external Actor requesting it
Use Cases focus on how someone or something uses a system – the usage model
Actors are used to abstract someone or something outside the
boundary of the system being developed
Benefits:
Easier to understand since they are written in the language
of the customer
Puts requirements into the appropriate context of system
responsibility
Facilitates re-use across iterations
8
9. IBM Rational Software Conference 2009
Typical Development Environments - Iterative
However, when adopting an iterative process, mistakes
can happen
RUP for example is a Framework – not necessarily
a specific process
There are over 2500+ web pages to sift through
Might be morphed into an artifact based process instead of
one that delivers value and resolves risk
Focus at first addresses technical Architectural Risks rather
than delivering Business Value to the customer.
“It’s a great design. Too bad we didn’t have it 3 months
ago when we really needed that front end piece.”
9
10. IBM Rational Software Conference 2009
Understanding Agile
Agile methods are not Cowboy programming as depicted by some
in the media
In fact, some of the key practices of Agile methods include:
Iterative and incremental development
Two levels of planning
Frequent releases
Self-organizing teams
Just-in-time requirements specification
Concurrent testing (developer & system)
Continuous Integration
Refactoring
Unit testing & Test Driven Development (TDD)
Retrospectives
10
11. IBM Rational Software Conference 2009
Understanding Agile
There is more than one method in the Agile camp. Each has its own strengths and
areas of focus
All Agile methods typically conform to the same basic Principles:
Lightweight, minimalist, low-ceremony
Highly collaborative: People over process and tools
Value-driven: Frequently provide value to end users
Embrace Change: Adapt instead of Predict
Feedback: Promote extremely tight response loop
Build Quality In: Adopt a “stop the line” mentality
11
12. IBM Rational Software Conference 2009
Understanding Agile
All Agile methods are adaptive in nature
The cadence of agility is to expect change for incremental release and to
react to those changes
This type of feedback allows the team to respond to change as opposed
to following a strict plan
Customers see results sooner and therefore have more input for what to
do next
12
13. IBM Rational Software Conference 2009
Agile Methods – Scrum Overview
Every project starts off with planning but many of today’s plans are educated
guesses that are padded for safety
Scrum is an Agile Project Management Framework based upon empirical evidence
Scrum does not prescribe specific software engineering technique such as requirements
gathering, testing, or development
13
14. IBM Rational Software Conference 2009
Agile Methods – Scrum Overview
Scrum uses two levels of planning:
Requirements, Features, Defects, etc. are all
organized into virtual work item lists called
Backlogs
The Product Backlog is managed by
a Product Owner who ranks each item
based upon the value it brings
Development is then done in a series of
time boxed iterations called Sprints
At the end of a Sprint, you have potentially
shippable code
14
15. IBM Rational Software Conference 2009
Agile Methods – Scrum Overview
Product Backlog
Estimated by the Team using relative
estimation measurements called
“Points”
Points are estimated per Backlog based
upon their size and difficulty relative to
other Backlog items
You don’t need all of the requirements
detailed before you can begin
Commitments to the requirements is deferred
until the Sprint planning begins
Requirements are detailed just-in-time for them to be worked
15
16. IBM Rational Software Conference 2009
Agile Methods – Scrum Overview
Sprint Backlog
This is a detailed iteration plan that is created by the team by pulling off items from the
Product Backlog
Each product backlog item is then broken down into individual tasks necessary to complete
the work
Each task’s work effort in is estimated collaboratively in hrs by the Team
Not to exceed 16 hrs
Team members then self-assign the tasks they want to do
Estimated remaining hrs for the task is updated by the individual team member daily
As an Online Shopper,
Develop middleware - 8 hrs
I want to be able to
browse for products Create UI - 4 hrs
Code tests - 4 hrs
Code xxx Class - 6 hrs
Refactor - 4 hrs
16
17. IBM Rational Software Conference 2009
Agile Methods – Scrum Overview
Daily Scrum
Each day, the team comes together to answer 3 basic questions:
What did I do yesterday?
What am I going to do today?
What’s in my way?
This is a short (15 minutes) meeting to give status to the rest of the team
It’s not to solve problems but rather to foster communication
It indicates commitment of the work items
Anyone can attend but only the Team, Scrum Master, and Product Owner can contribute
17
18. IBM Rational Software Conference 2009
Agile Methods – Scrum Overview
Sprint Review
At the end of the Sprint the team comes together to show their accomplishments during the
Sprint
Typically this is done as a live demonstration and the Product Owner can accept or reject
the changes
Rejections or defects are added back onto the Product Backlog
Accepted items’ relative point estimates are accumulated for the Sprint into a total known
as “Velocity” – which measures how much work a team can do in a Sprint
All team members participate in the demo
Does not require days of preparation. In fact it should be 2 hrs or less
Like the Daily Scrum, anyone can attend
Sprint Retrospective
After the Sprint review, the team comes together to discuss what went well and what
didn’t go so well
The goal is to self-improve
18
19. IBM Rational Software Conference 2009
Agile Methods – Agile Requirements Overview
User Stories are an Agile Requirements technique to describe discrete functionality
that benefits the customer
They encourage two agile principles:
Shifts the focus to conversation over the written word
Defers commitment until it is needed to build
Perfect size for planning purposes
Understood by the customer and the developer
Excellent for enhancing an existing application
They are smaller than a use case
19
20. IBM Rational Software Conference 2009
Agile Methods – Agile Requirements Overview
Each User Story is composed of three main parts:
A Short description no more than a sentence or two
Acceptance tests to confirm the story is complete
Verbal conversations that elaborate the story for understanding
Typically written by the Customer or Product Owner
They can be captured on a 5 x 9 index card or electronically captured in an agile
tool such as RTC
As an Online Shopper, As an Online Shopper, As Supply Manager, I
I want to be able to add I want to be able to pay want to be able to add
Front new products to sell
products to a shopping by credit card
cart
Must be able to specify quantity Must be able to pay by Visa Must be able to delete existing
products
Back Must be able to remove items Must be able to pay by Mastercard
Must be able to identify inventory
Must be able to continue shopping Must be able to pay by AMEX count
20
21. IBM Rational Software Conference 2009
Agile Methods – Agile Requirements Overview
Can be broken up into sub-stories if more detail is needed
Each story should be:
Independent
Negotiable
Valuable
Estimatable
Small
Testable
Organized in terms of: MoSCoW Rules
Must – Fundamental to the system
Should – important by not required
Could – could be left out
Won’t – not necessary this time around so it can wait
21
22. IBM Rational Software Conference 2009
Agile Methods – Agile Requirements Overview
Using the MoSCoW rules helps the Customer and Product Owner prioritize the
Product Backlog
Other techniques involve specifying whether this story is a Market Differentiator or
not
Those that may have more weight
Note that a Market Differentiator doesn’t have to be a Must category
The Product Backlog can be re-prioritized at any point in time
This gives the freedom to the Customer to control the feature efforts based on value to the
business – what a concept
22
23. IBM Rational Software Conference 2009
Agile Methods – Agile Modeling
Agile Modeling is an agile technique that is applied across multiple disciplines
The common thread in the above disciplines is that each of them have a common activity at
its core – that is the need to model
Models are an abstraction of a problem at a certain perspective using a common notation
RUP is very prescriptive about Models
Business Use Case models to system Use Case models
Domain models to Analysis models to Design models to Implementation models
Tools perpetuate this notion through their support of notations such as UML 1.x &
2.x, BPMN, BPEL, etc.
RSA for example, not only supports the 13 UML 2.x diagram types but also adds
additional diagrams like Topic and Browse diagrams. Do we really need all of them
for a project?
The short answer is: NO!!
23
24. IBM Rational Software Conference 2009
Agile Methods – Agile Modeling
There are really two kinds of models:
Formal models built with complex modeling tools
Informal models built on a whiteboard, digital picture, or simple modeling tools like Visio
Each model serves different audiences and a project usually has more than one
model
Models help teams think through a problem
a picture really does eliminate misunderstanding of the spoken word
All code ever developed came from one or more models
Either a formal set of diagrams, a whiteboard concept, or formed in the developer’s mind
before writing the code
Modeling can be extended into supporting practices such as MDD and MDA
24
25. IBM Rational Software Conference 2009
Agile Methods – Agile Modeling
Model when it’s
faster than writing
text
Original text was too
confusing. It needed
a model to be
explained
25
26. IBM Rational Software Conference 2009
Agile Methods – Agile Modeling
Adoption of Agile Modeling techniques means you only model what you can’t do
without
When it actually hurts your project not to have that model
Always model with a purpose in mind – not because it is “part of the process”
If it servers no purpose – don’t do it
Only model enough to support the effort
Don’t model for perfection. It just needs to be good enough to:
Get your point across
Meet the Intended Audience expectations
Clear and Detailed when necessary
Reliable
Simple
Holds value
There is a cost to maintaining models
26
27. IBM Rational Software Conference 2009
Agile Methods – Agile Modeling
Adopting Agile Modeling takes a certain approach.
Sometimes it really isn’t necessary to model at all
Do you need a model when all you are doing is adding a method to a class?
Agile models that are created and actually kept are a small percentage of the entire effort
Models that need to last longer than the project or for teams geographically distributed
are candidates to keep and maintain
When the cost of NOT having the model outweighs the cost of rebuilding it which slows
down development
Example keepers are Architectural Models, high visibility Activity steps, or complex
Business Rules
During Agile modeling, many models may be created but a large majority are transient and
are tossed once they serve their purpose
These rarely last past a few iterations
Examples would be some context or communication diagrams
27
28. IBM Rational Software Conference 2009
Agile Methods – Agile Modeling
Agile modeling efforts usually
don’t start in a tool
Whiteboards, Paper are perfectly
acceptable
The emphasis is to describe
visually an idea so that
conversation can begin
Shortens the development lifecycle Ali Ali - ATSC
by removing unnecessary diagrams
Saves money over time by reducing
the number of models to maintain
Have value and meet a specific
purpose for an intended audience
28
29. IBM Rational Software Conference 2009
Agile Methods – Test Driven Development
TDD came from XP but contrary to its name – it’s not really geared towards the
Testing Discipline in the RUP.
TDD is a design and programming activity more closely aligned with traditional unit
testing than formal testing done by professional testers
TDD allows developers to organically develop a test suite while building their
applications
In the past, developers would write code and then test it.
Unit Tests may had been done manually with little thought to the potential of breaking
something else
TDD uses automated tests to constrain each functional bit of a program
TDD is different in that you write the test first and when it fails you write code to
pass the test.
29
30. IBM Rational Software Conference 2009
Agile Methods – Test Driven Development
The TDD life cycle repeats until no more features
are left to build:
Add a test for the new capability feature
forces the developer to focus on the requirements
before writing the code instead of after
Run all tests and see if the new one fails
A form of negative testing using all prior tests
Write some Code to pass that test
Run the Automated tests to see them succeed
Refactor Code as necessary
Gain knowledge in knowing refactoring will not
damage any prior tests
30
31. IBM Rational Software Conference 2009
Agile Methods – Test Driven Development
The are several tools available by choice of programming language that supports
TDD such as:
JUnit, PHPUnit, TestNG to name a few
A 2005 study found the using TDD meant writing more tests; developers who wrote
more tests tended to be more productive
TDD can help build software faster by elevating the confidence level that new code
will not break existing code
TDD eventually builds the automated regression Test Harness that can be shared
among the team
TDD can be extended to Test Driven Database Development (TDDD)
31
32. IBM Rational Software Conference 2009
Agile Methods – Continuous Integration
In today’s world, not maintaining the code repository with all working parts becomes
a hectic task.
Developer takes a copy of the code base to write their code
Before the developer can check in their code, they must update their code base with that of
the repository to catch any changes made by others since (s)he checked out the code
The more changes that were made, the more work the developer must do before (s)he can
check in their code to the repository
Eventually the repository becomes so different from the developer’s that it may take more
time to integrate the changes than it did to write the new changes
This is what’s referred to as “Integration Hell”
Here is where an Agile practice called Continuous Integration (CI) helps out
32
33. IBM Rational Software Conference 2009
Agile Methods – Continuous Integration
Continuous Integration (CI) is simply the practice of integrating components early
and often
This mitigates the “Integration Hell” some development teams face
The build frequency is really left open to interpretation and project needs but it is
definitely more than once. The term “several times a day” is typically adopted
The ultimate goal of CI is to reduce that integration time and thus reduce timely
rework which ultimately saves costs
CI Emerged from XP but there are examples of this used by IBM in the 1960’s
when they were building OS/360
They created builds 4 times each day
33
34. IBM Rational Software Conference 2009
Agile Methods – Continuous Integration
Continuous Integration (CI) basic rules
Maintain a repository
The system should be buildable from a freshly checked out codebase that is not
dependent on other code
Rather than creating a new developer branch, it is preferred that changes are integrated
directly into the trunk
Because of the multiple builds, this is an acceptable practice
Automate the Build
Several tools support this such as:
Build automation tools: Make, Ant, Maven, ClearCase
Continuous Integration Servers: RTC, BuildForge, CruiseControl, TeamCity, etc.
This includes automating the integration in order to deploy to a production like environment
Include binaries, web pages, statistics, and possibly documentation
Make the Build Self-testing
Employ TDD techniques to test the code to confirm the behavior
34
35. IBM Rational Software Conference 2009
Agile Methods – Continuous Integration
Commit/Check-in Code Daily
This reduces the number of conflicting changes to others instead of committing weeks
worth of code at once
Each Team member must do this
Each Check-in to the mainline/trunk should be built
This confirms that the integration was successful
It can be a manual process or set up as an Automated CI that looks for changes and starts
the build
Keep the Build Fast
It can’t take hours for the build to complete. You want to know when a problem occurs
Test the Build in an environment cloned from production
This mitigates the errors where a Test environment doesn’t match the production
environment
35
36. IBM Rational Software Conference 2009
Agile Methods – Continuous Integration
Make the Builds Available
That means alerting testers and stakeholders early. This feedback loop reduces the
amount of time if the build doesn’t meet the requirements
Publish the Build Results
In an ideal world, the results of the build is transparent and made available to the entire
team
This is helpful to identify when a build breaks and what caused it to break
Automate the Deployment
Creation of a build can be extended by automating the deployment into the target
deployment model
36
37. IBM Rational Software Conference 2009
What’s the Game Plan?
Create a plan of attack
Bring in professionals to help assess your needs and plan
out the strategy of attack
Nothing helps jumpstart an organization like a set of experienced
professionals
The alternative is a number of whitepapers and books each
focused on a particular area
Look for a firm with experience who offers a robust set of service
offerings that directly relate to your pain points
37
38. IBM Rational Software Conference 2009
What’s the Game Plan?
Execute the Plan
Step 1 - Initial assessment of your needs
Step 2 – Putting it all together
Exposure to more than just one Agile method
Formal Training
Hands-on Workshops
Tool Training to reinforce the concepts learned
Ongoing mentoring with real pilot projects
Touchdown!!
38
39. IBM Rational Software Conference 2009
Step 1: Assessment
Every company is different, because of that there cannot be a single cookie-cutter
plan
Your company may already be strong in one area but weaker in another
Ensure an assessment reflects this and specifies a target set of solutions to
address these needs
Perhaps planning and delivery is the bottleneck, maybe it’s requirements
Note that the solutions are usually plural – that’s ok, as long as it is part of a cohesive plan
The assessment should include the existing development team size and location
In today’s world, development teams are sometimes distributed in multiple buildings,
states, or hemispheres
Professional firms who claim to be agile, need to be able to embrace this fact
39
40. IBM Rational Software Conference 2009
Step 2: Putting it all Together
Now that we’ve discussed various Agile methods, let’s put the thoughts down on
paper and plan how we can do it in around 40 days
Week 1
Conduct assessment and provision the tooling environment
Week 2
Conduct just-in-time training covering:
Detailed Agile methods
Hands-on Workshops
Agile tools (RTC, RRC, RQM)
Week 3
Pilot process and tools with hands-on mentoring from Agile coaches
Week 4
Agile Modeling, TDD & CI Workshops
40
41. IBM Rational Software Conference 2009
Step 2: Putting it all Together
Week 5
Mentoring the project with the Agile Coaches
Week 6
Retrospective
Plan next Sprint
The best way to introduce new concepts is not just by the theory of a book
Combining just enough theory with heavy hands-on workshops helps to reinforce
the concepts being described
Heavy emphasis should be on:
Collaboration
Planning
Instruction
Execution
41